IN THE DRAWINGS: 

Please add figures 4- 14(f) provided herewith. 

IN THE SPECIFICATION: 

Please amend the following paragraphs beginning at the designated page and line numbers as 
follows (the changes to these paragraphs are shown with strikethrough for deleted matter and 
underlines for added matter): 

Please replace the paragraph beginning at page 1 , line 15 in its entirety with the 
following: 

-- A user of financial system must log-on to the financial system before the user 
performs an action such as an inquiry or a transaction. If the user wishes to access another 
financial system, the user must log-on to the second financial system. Each financial system 
usually has its own menus and presents information in its own manner. Thus, a user, who 
wishes to access multiple financial systems, must remember multiple log-on user IDs and 
passwords and learn to operate each financial system. This process is time consuming and 
difficult. If the user wishes to access information from multiple financial system, the user 
access each financial system serially, create ti me lags between accesses. Additionally, some 
financial systems charge fees based on the user's actions. If a database provider, also called a 
data warehouse company, maintains the database for the financial institution and provides 
access to the users, the database provider charges access fees. However, access and fees are 
limited to fees associated with accessing the databases that the database provider maintains. - 

Please replace the paragraph beginning at page 2, line 27 in its entirety with the 
following: 

— Figure 3 is a diagram of an embodiment of a screen with multiple regions 
displaying real-time financial information from multiple record keeping systems 
simultan e ously, simultaneously; 

Figure 4 is one embodiment of a screen with a portfolio view; 
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Figure 5 is a representation of a bill showing the charges; 

Figure 6 is a representation of an embodiment of a system for accessing financial 
information; 

Figure 7 is a representation of an embodiment of a method of accessing financial 
information; 

Figure 8(a) is a representation of an embodiment of a screen for signing-on to the 
system of Figure 1; 

Figure 8(b) is a representation of an embodiment of a screen with a list of financial 
institutions that a user may access; 

Figure 8(c) is a representation of an embodiment of a financial institution menu 
window; 

Figure 8(d) is a representation of an embodiment of a shareholder account history; 

Figure 9 is a representation of an embodiment of a header portion of a message; 

Figure 10 is a representation of an embodiment of error codes for Figure 4; 

Figure 1 1 is a representation of an embodiment of a request message; 

Figure 12 is a representation of an embodiment of a response message; 

Figure 13 is a representation of an embodiment of a method of enrolling a user for 
accessing a financial institution; 

Figure 14(a)- 14(f) are representations of windows for enrolling a new user or adding 
access to additional financial institutions. — 

Please replace the paragraph beginning at page 6, line 9 in its entirety with the 
following: 

— For example, when the server 106 receives an inquiry for fund information, the 
server 106 determines which record keeping entity has the data for that fund. A request for 
an action is then transmitted to that record keeping entity. In a pref e rr e d e mbodim e nt, th e 
r e cord ke e ping syst e ms are dir e ctly conn e cted with th e s e rv e r 106, and th e routing includ e s 
port id e ntifications, wh e r e e ach r e cord k ee ping system is associated with a port. Preferably, 
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the request includes an action code or action indicator that indicates an action to be taken. 
Likewise, the response includes a response code or response indicator that indicates the 
status of the action. In one embodiment, the record keeping systems are directly connected 
with the server 106, and the routing includes port identifications, where each record keeping 
system is associated with a port. Preferably, the server 106 communicates with the first and 
second record keeping systems via a secure access, such as a direct connection. In this 
example, the server 106 is a trusted system and the first and second record keeping systems 
do not require the server 106 to be authenticated. The action can include an inquiry, a 
transaction, or other activity related to an account or fund. In a preferred embodiment, the 
record keeping systems are directly connected with the server 106, and the routing includes 
port identifications, where each record keeping system is associated with a port. Preferably, 
the server 106 communicates with the first and second record keeping systems via a secure 
access, such as a direct connection. In this example, the server 106 is a trusted system and 
the first and second record keeping systems do not require the server 106 to be authenticated 

Please replace the paragraph beginning at page 7, line 28 in its entirety with the 
following: 

— In another embodiment, the server 106 includes an access module and a user 
interface module. The access module accesses a plurality of independent substantially real- 
time financial record keeping databases. The user interface module receives requests and 
presenting results relating to the plurality of independent substantially real-time financial 
record keeping databases. The user interface module presents a uniform set of user displays 
for accessing the independent substantially real-time financial record keeping databases. 
Some of the modules described above may be implemented separate from the server 106, 
such as on the computer 104. — 

Please replace the paragraph beginning at page 8, line 4 in its entirety with the 
following: 

4 



— The user provides authentication information, such as a user identification and 
password. Preferably, the user establishes an account by accessing an Internet based site and 
entering a user ID and password. Then the user enters contact and verification information 
that includes user's name, address, social security number, phone number, e-mail address, 
and other information. During subsequent accesses, the user enters the user ID and 
password. When a user has forgotten a user ID or password, a message containing the 
forgotten information can be sent to a secure e-mail system, such as DST Systems 1 ePriority 
system. Alternatively, a user enters information such as social security number, and/or date 
of birth to verify their identity, and the forgotten information is presented to the user. Once 
authenticated, the user enters an identification or identifications of the account holder(s) that 
the user wishes to get information about. A request for account information associated with 
the account holder identification(s) is sent to various record keeping systems. A response is 
received from those record keeping systems. — 

Please replace the paragraph beginning at page 9, line 10 in its entirety with the 
following: 

-- While financial intermediaries accessing mutual fund accounts have been used as 
an example, the present invention as defined by the claims can be applied to other financial 
accounts such as annuities, credit accounts, bank accounts, and other financial accounts. 

Optionally, the system 100 allows the user to maintain multiple portfolios having 
different accounts within each portfolio. For example, a user has a first portfolio with 
accounts that are part of a 40 IK plan, a second portfolio with accounts that are not part of a 
40 IK plan, and a third portfolio with the accounts in the first and second portfolios. Each 
portfolio includes accounts from one or more different financial institutions, and the account 
data is maintained by the same or different record keeping companies. The user edits, 
deletes, and creates new portfolios as desired. 

In one embodiment, the system 100 accesses no-load mutual fund data from a 
plurality of financial institutions maintained on a plurality of record keeping systems. The 
user accesses the account information by navigating a set of screens. A single user ID and 
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password gives the user access to the plurality of accounts. The user performs inquiries, 
transactions, and account servicing for each of the accounts. Optionally, a consolidated view 
of the user's accounts is presented. 

Optionally, the provider of the services described above charges fees for accessing the 
account information. It is preferred that the fees be charged to the financial institutions. 
Alternatively, the account holder, a third party, or a combination thereof is also charged. 
Possible fees include: setup fees, monthly operator ID fees, per view fees, per transaction 
fees, registration fees (also called new account fees), monthly minimum fees, and other fees. 
Optionally, advertising fees are charged for advertisements that appear on a screen. 

For example, the fee are as follows: inquiry view fee $0.05, user ID fee $5 per month 
per financial institution, purchase fee $0.50, redemption fee $0.50, exchange fee $0.50, new 
account fee $3, account position inquiry $0.05, account history inquiry $0.05, portfolio 
position inquiry $0.05, transactions $0.50. Alternatively, the fees are inquiry views $0.05 
and transactions $0.50. Different fees, combinations of fees and/or fee amounts may be 
used. 

The user performs actions including inquiry, transactions, and account maintenance. 
The inquiry actions include portfolio positions (shares price, market value, etc.), portfolio 
history (transactions across accounts, etc.), account details (registration, dividend options, 
account options, etc.), and account history (transactions within an account). The transaction 
actions include purchases by an automated clearing house (ACH) to new or existing 
accounts, redemption by ACH, withdraws by check, withdraws by wire, exchanges to new or 
existing accounts within the same fund family, and exchanges to new or existing accounts 
across fund families. Account maintenance actions include ordering duplicate statements, 
viewing statements on-line, ordering duplicate tax forms, viewing tax forms on-line, viewing 
year-end information, ordering checkbooks, changing address, updating distribution options, 
adding/updating systematic agreement files, updating bank information, establishing new 
accounts, and averaging costs. Other inquiries, transactions and/or account maintenance 
actions may be provided. 



6 



In a preferred embodiment, the system provides financial planning capabilities 
including asset allocation graphs by investment and Morningstar data or other value service 
data. 

Optionally, the server 106 charges for access to real-time financial information stored 
on independent systems and includes an access module and a fee module. The access 
module provides user access to a first real-time financial account on a first system and a 
second real-time financial account on a second record keeping system. The first account 
being associated with a different financial institution then the second account. The fee 
module calculates at least first and second fees based on accesses to the respective first and 
second financial institutions. The fees are a function of user initiated activities. Optionally, 
the fee module includes a billing module that transmits a bill electronically. -- 

Please replace the paragraph beginning at page 13, line 20 in its entirety with the 
following: 

— Figure 4 shows a screen 400 with a portfolio view. The screen 400 includes a title 
area 402, a portfolio selection area 404, a portfolio data area 406, a portfolio option area 408, 
and a message area 410. 

The title area 402 includes an application title, for example "Vision Direct" and a 
window title, for example "Portfolio View." The portfolio selection area 404 allows the user 
to select a portfolio. 

The portfolio data area 406 includes various information relating to the user's 
accounts. In one embodiment, the portfolio data area 406 includes the fund name, account 
number, current price, daily change in dollars per share, daily percentage change, number of 
shares, and current market value. The portfolio data area 406 may include other information 
about the accounts in the portfolio. The portfolio data area 406 also includes a portfolio total 
that represents the total value of the accounts displayed. Additionally, totals for the accounts 
in each financial institution may be included. In one embodiment, the portfolio data area 306 
includes a date field that allows the user to access the information as of a specified date. 
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In one embodiment, the portfolio option area 408 includes options to view a portfolio 
history, setup a new portfolio, and change a portfolio. 

The message area 410 includes instructions or messages for the user. For example, 
the instructions include instructions on how to view account details, how to view fund 
information, and how to visit a fund family's web site. 

Optionally, other screens display various types of account and fund information. 

Figure 5 is a representation of a bill 500 that includes a header area 502, an identifier 
area 504, and a charges area 506. The header area 502 indicates the source of the bill, 
"Vision Mutual Fund Gateway" and the type of bill, "Monthly Billing Summary Report." 
The identifier area 504 includes such information as the report number, source program, job, 
system, corporate billing ID, management company code, and billing period. The charges 
area 506 includes summary data on the charges for the period identified in the identifier area 
504. The charges area 506 includes the number of action and the charges for those actions. 
The actions include views, vision IDs, purchases, redemptions, exchanges, and new 
accounts. The calculation of the charges associate with the actions are described below. 

Revenue is generated for the entity providing access to financial information. For 
example, the entity is an entity operating the server 106 (Figure 1), provides access to the 
user via the Internet, and providing access to various record keeping systems. Some of the 
record keeping systems may be provided by the same entity as the server 106 while other 
record keeping systems are provided by other entities. Each record keeping system 
maintains data on one or more financial accounts, such as mutual fund account in one or 
more financial institutions. Optionally, the mutual fund company maintains the record 
keeping. 

The service provider, usually the company maintaining the server 106 (Figure 1), 
generates revenue by charging one or more of the following fees: a setup fee, a monthly 
operator ID fee, a per view fee, a per transaction fee, a registration fee (also called a new 
account fee), a monthly minimum fee, and other fees. 

The setup fee is charged for establishing access to a new financial institution through 
the server 106 (Figure I). For example, if a mutual fund company wishes to provide access 
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to accounts through the server 106, the service provider charges a setup fee. The setup fee 
may be any amount, such as $1,000, $5,000, $1,000,000, or another amount. The setup fee 
may be varied based on whether the financial institution is maintaining data on a record 
keeping system maintained by another entity or is maintaining its own data. For example, 
the setup fee for a financial institution maintaining its own data is half of the regular setup 
fee. In a preferred embodiment, the setup fee is $5,000 for new customers and $2,500 for 
existing customers. Preferably, the setup fee is charged to the financial institution. 

The operator ID fee, also called user ID fee and user identification fee, is charged 
periodically, for example monthly, for each operator that has access to each account. If an 
operator has access to more than one account (or fund), then that operator ID fee charged for 
each account. 

The operator ID fee is any amount, including $0.05, $0.50, $1, $2, $3, $4, $5, $100, 
or more. Discounts can be provided for higher volume financial institutions. The discounts 
are based on a graduated fee basis in one embodiment. For example, the first 500 operator 
IDs are $5/ea. per month, the next 500 operator IDs $4/ea. per month, the next 1000 operator 
IDs are $3/ea. per month, the next 1000 operator IDs are $2/ea. per month, and each operator 
ID beyond 3000 is free. In this example, the maximum fee would be $9,500/mo. 

The view fee is charged for viewing the result of an inquiry. The inquiry may include 
information from several accounts and only one view fee is charged. Alternatively, the view 
fee is based on the number of accounts accessed. For example, the view fee is $0.01, $0.05, 
$0.10, or an other amount per view. Preferably, the view fee is charged to the financial 
institution. 

The transaction fee is charged for each transaction performed. Transactions include 
purchases, redemptions, exchanges, and/or other transactions. The transaction fee is $0.01, 
$0.5, $0.50, or another amount per transaction. Preferably, the transaction fee is charged to 
the financial institution. 

The new account fee, also called a registration fee, is charged for each new account. 
In a preferred embodiment, a single new account fee is charged when multiple accounts for 
the same shareholder or owner are established at the same time in the same mutual fund 
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family. The new account fee is $0.50, $1, $3, $5, or an other amount. Preferably, the new 
account fee is charged to the financial institution. 

The monthly minimum fee is charged when the total of the other monthly fees are 
below a desired level. For example, the monthly minimum fee is $100, $500, SLOOP, or an 
other amount. The monthly minimum is based on a per user ID basis, a per fund basis, 
and/or a per financial institution basis. Optionally, the monthly fee is based on the size of the 
financial institution, the number of accounts, and/or other factors. Optionally, the monthly 
minimum varies depending on whether the server 106 (Figure 1) provide financial 
transactions for the financial institution. For example, the monthly minimum fee is $500 if 
the server 106 provide financial transactions and responds to inquiries and $0 if the server 
just responds to inquiries. 

Discounts may be provided for any type of fee or for any combination of fees. 
Minimum and maximum fees may be assessed for any type of fee or combination of fees. 
The fees for any type of fee may be graduated. The graduated fees can increase or decrease 
as the use of the server increases. Preferably, the fees are charged to the financial institution 
being accessed. However, in the alternative, the user or a third party is charged. 

Figure 6 is another representation of an embodiment of a system 600 for accessing 
and presenting financial information. The system 600 includes a plurality of computers 601, 
602, 603, each running a standard WEB browser or other communication program for 
accessing the server 605. Each computer 601, 602, or 603 comprises a personal computer, 
terminal laptop, palmtop, mainframe, or other device capable of communicating with the 
server 605. The computers 601,602, 603 access the server 605 via an intranet or other 
network, such as the Internet, or via a direct communication line. The server 605 
communicates with the computers 601-603 and a plurality of record-keeping systems, for 
example, the first record-keeping system 608 and the second record-keeping system 610. 
The computers 601-603 may execute an application for communicating with the server 605. 
The server 605 may execute an application or group of applications for communicating with 
the computers 601-603 and the first and second record-keeping systems 608, 610. 
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According to one aspect, the first and second record-keeping systems 608, 610 are 
owned by different entities, such as fund companies. The server 605 may be owned by the 
same entity that owns one of the first and second record-keeping systems 608, 610. 

The records stored in the first and second record-keeping systems 608, 610 are stored 
in different formats, but a same format may be used. The record-keeping systems 608, 610 
have different or the same data structures, and/or operating systems. The record-keeping 
systems 608, 61 Pare controlled by a data warehouse company that maintains the data for a 
financial institution, or the financial institutions. 

The records stored in the first and second record-keeping systems 608, 610 include 
account information, such as mutual fund accounts, annuities, and other financial 
information, and fund information, such as yield to date, net asset value. 

A user at a computer 601, 602, 603 accesses the information stored on the first and 
second record-keeping systems 608, 610 through the server 605. It is preferred that the 
users include financial intermediaries. The server 605 maintains several databases that track 
relationships. The relationships are stored in tables, database, flat files, or with other 
mechanisms. These databases include the user ID and password used for user authentication 
or log-on. The databases include the relationship between the user ID and record-keeping 
systems user IDs. For example, a user signs-on to the system 600 using a user ID and 
password. When that user accesses a record-keeping system 608, 610, the server 605 
determines an internal ID for the record-keeping system 608, 610 associated with the user ID 
and password. In an alternative embodiment, the server 105 determines an ID and password 
for the record-keeping system associated with the user ID and password used to sign-on to 
the system 600. The server 605 sends a request for information to the record-keeping 
system with the a user ID, which is the system user ID or the internal user ID. Thus, a user 
need only remember the user ID and password for signing-on to the server 605, and need not 
know the user IDs for the record-keeping systems. Each record-keeping system may know 
the user by a different internal user ID or use the same user ID as the server 605. 

The server 605 also maintains the relationships between the system user ID and the 
financial companies that the user can access. For example, after a user logs-on to the server 
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605 with a user ID and password, a list of fund families is presented. The list includes the 
funds that user is allowed to access. In one aspect, the list includes just the funds accessible 
to the user. Fund families also comprise fund companies, mutual fund companies, financial 
institutions, and management companies. The list of authorized fund families is based on 
the relationships stored in the database. 

The server 605 also maintains a routing table. The routing table includes the 
relationship between the fund companies and the record-keeping system where their financial 
data is stored. Financial data includes account data and fund data. For example, when the 
server 605 receives an inquiry for fund information, the server 605 determines which record- 
keeping company has the data for that fund. A request is then transmitted to that record- 
keeping company. In a preferred embodiment, the record-keeping systems 608, 610 are 
directly connected with the server 605, and the routing includes port identifications, where 
each record-keeping system is associated with a port. 

Financial intermediaries are often associated with dealer, branch, and representative 
identifiers. The record-keeping system may maintain the relationships between user ID and 
dealer, broker, and representative. The user ID may be the user ID used to log-on to the 
server or the internal user ID assigned by a record-keeping system. 

Alternatively, the server 605 maintains relationships between a user's user ID and the 
dealer, branch, and representative associated with the user ID. The dealer, branch, and 
representative are provided to the record-keeping system in a request for information or a 
request for a transaction. 

The server 605 dynamically builds the HTML pages that are sent to the clients' 
browsers. The server 605 decodes a request from a client's browser into a transaction 
request and forwards the request to the Protocol Converter and Switch 606. The switch 606 
determines, by referring to the cross-reference database 612, which record-keeping system 
has the requested data. The switch 606 translates and forwards the request into a format and 
protocol that the target record-keeping system supports and forwards the request to the target 
record-keeping system for processing. Once the record-keeping system has satisfied the 
request, it sends a response to the switch 606. The switch 606 converts the response into a 
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transaction response and sends the response to the server 605. The server 605 decodes the 
transaction response and dynamically builds the HTML pages to be delivered and displayed 
in the client's browser. The switch 606 handles data translations, for example between 
ASCII and EBCDIC. 

Referring now to Figure 7, a flow diagram 700 of the method of accessing specific 
information associated with a financial institution is shown. When a user signs-on to the 
system of Figure 1, the server 105 sends the first user ID and password for authentication in 
act 701 . The first user ID may be the Vision ID according to one embodiment. Figure 8(a) 
shows a sign-on window according to one embodiment. The system is secured by a user ID, 
which can be restricted at dealer, dealer/branch, and dealer representative access levels or by 
a tax ID. The type of security associated with a user ID will affect the account information 
displayed on computers 601, 602, and 603. The password is encrypted and compared against 
the encrypted password. 

After password authentication, a list of financial institutions that the user is authorized 
to access is presented to the user. The list of authorized financial institutions is determined 
by referring to a cross-reference database maintained within a data base, such as the User ID 
Cross-reference Database 612 (Figure 6). Figure 8(b) shows an example of a list of financial 
institutions from which the user may access financial information. To add additional 
financial institutions, the user may click the "Sign up for Vision" hyperlink on Figure 8(a) to 
go to Vision enrollment WEB site. 

In act 702 (Figure 7), the user selects one of the financial institutions from the 
displayed list to request specific financial information. The switch 606 determines in act 703 
whether the requested financial information is on the first record-keeping system. The 
switch 606 refers to the cross-reference database of financial institutions to the user ID 
maintained in the User ID Cross Reference Database 612 (Figure 6). 

If the selected fund is on the first record-keeping system 704, the server 605 sends in 
act 705 a request to the first record-keeping system. This request includes a first 
identification code, which may be the system user ID. The server 605 then receives in act 
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706 a response from the first record-keeping system. The server 605 presents in act 707 the 
response to the user, via e-mail fax, or postal mail 

If, however, the requested financial information is on the second record-keeping 
system 708, the request for specific information received from the user is sent from the 
server 605 to the switch 606. In act 709, the switch 606 determines an internal identification 
code from the cross-reference database if one has been assigned to the user. In act 705 the 
switch routes the request to the second record-keeping system. The request includes the 
second identification code. The second identification code includes the internal identification 
code or the first identification code. In act 706 the server 605 then receives a response from 
the second record-keeping system. The server 605 presents in act 707 a portion of the 
response to the user. 

Figure 8(c) shows a financial institution menu window for Global Prime Investor 
Funds, which the user may select from the list in Figure 8(b) in one embodiment. This 
window provides options for accessing detailed information about the Fund Company. 
Figure 8(d) shows a "Shareholder Account History" screen displaying transaction history 
information for an account within the funds. Vision provides real-time, up-to-date fund and 
shareholder account information. 

Communications between the server 605 and the record-keeping systems 608, 600 are 
via messages. The messages have a unique identifier name and may have a method to match 
responses with the corresponding requests. Each message, being a request or a response to a 
request, comprises a header portion and a data portion. For example, for accessing an 
Account History, the header and account history request data are sent to the record-keeping 
system associated with the financial information. In the response from the record-keeping 
system, the header and account history response data will be returned. 

Figure 9 shows an example of a header record 900 according to one embodiment. 
This header is sent with a request or response message. The header includes one or more: 

(1) length fields that indicate the length of the message (packet) and/or the length 
of data portion 901; 

(2) a transaction ID 902, for example ACCTHIST@VISION for the Account 
History request, that indicates a transaction to be performed; 
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(3) the source of the a message 903; 

(4) a source tag 904, which should be returned in the response header; 

(5) the user ID 905 used to sign-on to the system or the internal user ID assigned 
by the second financial institution; and 

(6) error messages 906 used by the target system to indicate which error occurred. 
Figure 10 shows a list of error messages, which include error codes indicating 

whether: 

( 1 ) a severe system error has occurred 1001; 

(2) files are unavailable for read access 1002; 

(3) the user ID is not authorized 1003; and 

(4) the target fund or the system is unavailable to process the request 1004. 
Other fields and/or messages may be used. 

The data portion of a request defines the specific information the user is desiring to 
access. The data portion of request messages and response messages may be fixed or variable 
length. An exemplary list of a DST request data portion in the Vision system is described on 
pages 34-133 of Appendix B. 

Figure 1 1 shows one embodiment of a data portion of a fixed length transaction 
message 600 for requesting an account history. The request data 1 100 includes: 

(1) a first field 1101 for identifying the selected fund; 

(2) a second field 1 102 for identifying a shareholder account ; and 

(3) a third field 1 103 for indicating an index for requesting additional accounts. 

Other fields and/or messages may be used. 

Figure 12 shows an example definition of a data portion of a response message 1200 
sent by a record-keeping system in response to an account history request. The data portion 
1200 includes various fields: 

(1) optionally, the type of transaction 1201; 
(2) the number of shares 1202; 

(3) the amount of the transaction 1203, preferably in dollars; 

(4) the cumulative share balance of an account 1204; 

(5) the date of the transaction 1205; and 
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(6) a transaction description 1206. 
Other fields and/or messages may be used. 

According to another aspect of the present invention a method of enrolling a user for 
accessing financial information from a financial institution is presented. A user requesting 
access to financial information associated with a financial institution accesses an online sign- 
up. The sign-up procedure generates a user ID setup request e-mail that is automatically sent 
to the service provider. Upon receipt, the service provider forwards an authorization request 
to the appropriate financial institution(s) for approval This request contains the pertinent 
information needed to verify the operator's request and the user ID. Other sign-up 
procedures may be used, such as in response to written or voice instruction. 

The financial institution replies to the request. The financial institution may choose 
to provide its own user ID; however, if none is provided, the system user ID is used. If the 
financial institution chooses to provide its own user ID, this ID will be maintained on the 
cross-reference database 612 (Figure 6). Thus a user is able to sign-on to the system with 
one user ID and password to access many accounts. 

Figure 13 shows one embodiment of a flow diagram 1300 of the enrollment process. 
In act 1302 a user requests access to financial information. In act 1304, the user is requested 
to provide certain information to the system 600 in Figure 6. The user information may be 
received via a standard client WEB browser running on one of the computers 601-603, via 
phone, via e-mail, or via postal mail 

Figure 14(a) shows a screen for a new user enrollment or for adding additional funds 
to the list of authorized funds for an existing user, according to one embodiment. Figure 

14(b) shows the new user window after the user has selected the iconJabeled "New User 

\ 

Enrollment" 1401 in Figure 14(a). When the user clicks on the icon "Enrollment Forms" 
1402, the enrollment form, as shown in Figure 14(c), appears. This form allows the user to 
select one or more of the access levels 1403-1406. The access levels include dealer level, 
branch level, representative level, and Tax ID level. Figures 14(d)- 14(f) show the windows 
for providing user information when the user selects the respective access levels 1403-1406. 

In act 1305 (Figure 13), the server 605 establishes a first user ID and password for the 
user based on the user information. The first user ID has a unique association with each 
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individual financial institution or fund company that has been authorized for the user. This 
association allows the Fund Company's name to be listed on the main entry window or 
display after the user signs-on. The server 605 supplies the first user ID to the selected 
financial institution so that the financial institution applies the appropriate security and 
access control Several different types of intermediaries use the system 600, so the system 
600 supports different levels of account access. Preferably, accounts linked to the user are 
accessible with a single log-on. 

In act 1306 the switch 606 translates the request into a format and protocol that the 
financial institution supports and forwards the translated request to the target financial 
institution. The financial institution processes the request and may authorize the user to 
access financial information, may decline access to financial information, may indicate that 
information supplied from the user is not correct, or may modify the user-specified access 
levels for accessing the target record-keeping system. The switch 606 receives the access 
authorization information from the financial institution in act 1308, converts the response 
into a system transaction response, and sends the converted response to the server 605. The 
server 605 decodes the transaction response. 

In optional act 1310 the target financial institution assigns an internal user ID for the 
user. The server 605 cross-references the system user ID with the internally designated user 
ID in a database 612 (Figure 6) in act 1312, such that the user just needs to know the system 
user ID when accessing the financial information from financial institutions associated with 
both first and second record-keeping systems. If, however, the financial institution chose not 
to assign an internal user ID 1316, the server 605 provides the system user ID to the user in 
act 1314, and the system user ID is used for future access of the financial institution 
associated with both the first and second record-keeping systems. The user uses one user ID 
and password to access both financial institutions, such as accessing TA2000© and non- 
TA2000 financial institutions with the same user ID and password 

An example of the enrollment process discussed above for the Vision system is as 

follows. The DST receives a request from representative, Sarah Williams, for Vision access 
to the ABC financial institution, which is a non-TA2000 system. The DST sends the request 
to the ABC financial institution, and references Sarah's DST-assigned Vision User ID 
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"VS00001693." The ABC financial institution chooses to assign Sarah an internal user ID 
"ABC0000067." DST cross-references these two IDs in the cross-reference database 612 
(Figure 6). 

When Sarah Williams desires to access a specific financial information from the ABC 
financial institution, Sarah signs on to the Vision system 100, through the window shown in 
Figure 8(a), with the DST assigned Vision user ID "VS00001693." As mentioned above, this 
Vision user ID provides Sarah automatic access to the ABC (non-TA2000) financial 
institution, by means of the cross-reference database 612 (Figure 6). 

In another example, when the DST receives a request from Sarah for Vision access to 
the XYZ financial institution, which is also a non-TA2000 system, the DST sends Sarah's 
request to the XYZ financial institution, and references Sarah's DST-assigned Vision User 
ID "VS00001693." However, the XYZ financial institution chooses not to assign Sarah an 
internal user ID. The switch 606 (Figure 6) uses Vision User ID "VS00001693" for 
accessing the XYZ financial institution. When Sarah desires to access specific financial 
information from the XYZ financial institution, Sarah signs-on to the Vision system 600 
(Figure 6) with the DST-assigned Vision User ID "VS00001693." As mentioned above, this 
Vision ID provides Sarah direct access to financial information from the XYZ (non-TA2000) 
financial institution. 

The authorization request, which is sent to a target financial institution, includes the 
user ID and the user information entered by the user, through the windows shown in Figures 
14(c)-14(f), in one embodiment, such as the user's name, address, phone number, and the 
user-demanded access levels. 

The authorization response includes the user ID, access information, and the internal 
user ID. The access information may either include information confirming the access levels 
that the user had demanded, or information modifying the user-demanded access levels. For 
example, if the user had demanded a dealer number 123 and a representative number 345, the 
target financial institution may approve the dealer number 123, but may change the 
representative number to 678. 
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The following appendices are hereby incorporated by reference: Appendix A, entitled 
"Vision Mutual Fund Gateway Training Guides" and Appendix B, entitled "Vision Mutual 
Fund Gateway External Funds Technical Manuals." — 
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